メトリクスを Sumo Logic に取り込んで、ホストサーバの稼働状況を監視するダッシュボードを作成してみた
最初に
メトリクスはシステムの稼働状況を把握するのにとても大切な指標となります。 システム稼働状況を把握することで、エラーやボトルネックを把握することに繋がり、安定したサービスの提供を行えます。 また、トレースのログも取得していけばアプリケーションを最適な状態に導くことも出来ますが、そのためにまずはログとメトリクスの監視が必要です。
今回は、AWS EC2 Linux の稼働状況を知るために Sumo Logic という SIEM 製品にログとメトリクスを収集して、クエリやダッシュボードの作成をしてみました。
メトリクスを収集する意義
メトリクスデータを集めることには多くのメリットがあります。
- トラブルシューティング
- 改善
- 計画
- セキュリティ
- レポート
システムやアプリケーションにおける問題の原因や場所の特定に繋がります。
稼働状況を見てボトルネックを把握できます。特定箇所における性能の低下などの改善に役立ちます。
リソースの使用状況を把握できます。これにより、将来プロビジョニングするリソース容量を知ることが出来ます。
システムの異常を検知出来ます。大量のトラフィックやアクセスを特定してセキュリティ脅威に対処できます。
システムやアプリケーションの稼働状況をレポート化することが出来ます。性能検証、拡張などの将来の改善のためにメトリクスで得られた洞察を利用できます。
この様にメトリクスデータを扱えるということは、システムの安定性や、将来性に繋がる非常に不可欠な要素と言えます。
何のメトリクスを収集すればいいのか
それでは、どのようなメトリクスデータを収集すればシステムの安定性や保全に役立つのかについてです。 こちらは監視するシステムやアプリケーションごとに異なりますが、一般的に下記の項目が該当するといえます。
- CPU使用率
- メモリ使用量
- TCP
- ネットワークトラフィック
- ディスク使用量
ログも取得すると、より一層の分析効果が見込まれます
上記、メトリクス項目に加え、下記のようなログも取得していただくことで原因究明やボトルネックの調査、拡張の有無の判断に役立ちます。
- アプリケーション / イベント
- ユーザビリティ
- セキュリティ
システムやアプリケーションのログをメトリクスと掛け合わせることで問題の特定に役立ちます。
アプリケーションの応答時間やエラーメッセージとその数など、ユーザエクスペリエンスに直結するログも収集することで原因究明に繋がります。
ログインの失敗や不正なアクセスの試行回数など、安定稼働を損なる異常なアクティビティを監視するために使用できます。
Sumo Logic でメトリクスを収集 / 管理 / データ運用する
それでは、これより AWS EC2 で稼働している 検証用 Apache WEB サーバのホストメトリクスを収集していきます。
大きくは、下記のようなフローになります。
- EC2 サーバに Installed Collector をインストールする
- メトリクスの Source を作成
- データの受け取りを確認
- メトリクスのクエリを作成
- ダッシュボードの作成
それぞれ解説を交えて順番にやってみます。
EC2 サーバに Installed Collector をインストールする
Installed Collector は、Sumo Logic が提供しているログやメトリクスを収集する Java 製のソフトウェアです。まずはこちらをインストールしてログやメトリクスデータの収集を開始できます。本記事では行っておりませんが、Java の実行環境が必要になるので、ない場合は、JRE もインストールする必要がございます。
ちなみに今回ご紹介させていただいている Installed Collector 以外にもデータの収集方法はたくさんございます。各データ収集方法の詳細は Send Data | Sumo Logic Docs でご確認いただけます。
では実際の手順についてご説明します。
まずは、Sumo Logic にログインをしていただき、左下のメニューバーで Manage Data > Collection を選択。 その後、画面右上の Add Collector > Installed Collector を選択します。
対象の Installed Collector を選択します。
ちなみに Installed Collector は JP Collector download URLs | Sumo Logic でもダウンロードいただけます。そのため、wget コマンドなどで取得することも可能です。なお、本記事では行いません。
そうしたらダウンロードした、SH ソースファイルをサーバに配置して、コマンドラインでインストールしていきます。 まずは .sh ファイルに実行権限を付与します。
chmod +x SumoCollector.sh
そして、インストールした後で Sumo Logic と安全に通信するために Sumo Logic の画面でトークンを発行します。Add Token | Sumo Logic を参考に GUI で作成できます。トークンを発行したら、-Vsumo.token_and_url=の後に続けて記載してください。
sudo ./SumoCollector.sh -q -Vsumo.token_and_url=トークン
インストールが完了したら、下記の様にヘルスランプが緑点灯しているかを確認します。緑点灯 = 正常。赤点灯 = うまくインストールできてないか、HTTP 443 のアウトバウンド通信が出来てない状態です。
ちなみに Installed Collector のインストールと次の工程である Source の作成は、コマンドだけで完結させることも出来ます。Host metrics source | Sumo Logic にある JSON の例を参考に source.json ファイルを作成してサーバに配置後、下記 -Vsource= の後ろにパスを記載してください。なお、本記事では行いません。
sudo ./SumoCollector.sh -q -Vsumo.token_and_url=トークン -Vsources=ソースの構成要素
メトリクスの Source を作成
ここまでで、Sumo Logic にデータを配信するためのコレクター配備が完了しました。 次に Sumo Logic のプラットフォームで、取得するデータのカテゴライズを行う工程として、Source というデータを入れる箱を作成します。
Collection の画面で、対象のホスト名を探し、Add... > Add Source を選択。
そして、下記の赤いアスタリスクがついた必須項目を入力します。SourceCategory の項目も後々、ログが増えることを考慮して分かりやすく記入してください。SourceCategory の命名規則については弊社ブログの Sumo Logicのログ収集設計時に最初に考えること | Developesio で解説しております。
Scan Interval は、送信するメトリクスデータの解像度を決めます。デフォルト１分に１つのメトリクスデータを送信します。Metrics は、表示されている CPU、Memory、TCP、Network、Disk の項目の中でも、詳細にどのメトリクスデータを取得するか選択できます。詳しくは Host Metrics Source - Collected Metrics | Sumo Logic をご確認ください。
完了したら Save を押下します。
データの受け取りを確認
インストールした Installed Collector と Source の設定が正しく行われており、データが入ってきているかを確認します。
メトリクスのクエリを作成
データを利用するために実際にクエリ文を書きます。主に後の手順でデータの可視化を行えますが、クエリ文を使うことでカスタマイズ性が向上して、要件 / 課題に沿った分析も行いやすくなります。
Sumo Logic では、パイプ（|）で区切って条件をつけ足してクエリ文を書いていきます。
赤枠の部分は、先ほど設定した SourceCategory でデータを指定しています。
_sourceCategory=Linux/Host/Metrics
青枠の部分は、Host Metrics Source - Collected Metrics | Sumo Logic で、組み込みのメトリクスメタデータを使用できるので、こちらをクエリ条件のターゲットとしています。ここでは、CPU の過去 1分間のシステム負荷平均値を取り出しています。
metric=CPU_LoadAvg_1min
緑枠の部分は、Metrics Operators | Sumo logic の平均値を求める avg 演算子を使用しています。これにより、時系列で入ってくるメトリクスデータの平均値を求める条件を与えています。
| avg by metric
これらが一体となって検索結果はこのように表示されます。もちろん、グラフはカスタマイズ可能です。後に別のグラフを載せてます。
また、これは1分の平均でグラフを作成していますが、例えば、5分、15分と間隔を伸ばした場合で平均値を出したらどうなのだろう？というときは、下記 + ボタンでクエリ式を追加することも出来ます。
平均値をとる時間の間隔を伸ばした場合はこちらです。
この様にカスタマイズ性も高く、このままダッシュボードに追加することも出来ますし、値を監視するアラートを作成することも出来ます。
ダッシュボードの作成
また、App Catalog という組み込みのテンプレートがありますので、そちらで簡単にデータをダッシュボードに落とし込み、可視化することが出来ます。
App Catalog > Host Metrics を選択します。
そしたら、Add Integration で、ダッシュボードを作成していきます。
Source 作成時に設定した SourceCategory を選択して、ダッシュボード保存先を選択して、NEXT を押下します。
すると、Success!! と出るので、左カラムのフォルダを確認すると、先ほど設定した名前でダッシュボードが作成されていることが分かります。
Overview というのが、生成されたすべてのダッシュボードの概要を表示するもので、その他 ○○ - CPU、○○ - Memory などは、それらに特化したより詳細なダッシュボードです。Overview を見てみます。
このようにデータが入り、各項目を表示できることを確認できました！今回ご紹介させていただいたダッシュボードについては、Host Metrics Sumo Logic App | Sumo Logic で詳細を確認できます。また、App Catalog の数が非常に多いのでご紹介しきれませんでしたが、App Catalog | Sumo Logic で各種確認できます。
それでは、Sumo Logic を選ぶメリットについて、ご紹介させていただきます。
Sumo Logic を選ぶメリット
- オンプレ / クラウドに対応
- 拡張性
- ログとメトリクスの統合
- AppCatalog の利用
- 高度な分析能力
オンプレミスはもちろん、AWS や MS Azure、GCP などのパブリッククラウドに対応しております。さらに非常に多くの SaaS 製品ログも収集できるため、EDR や CASB、UEBA なども含めて包括的に、そして製品を横断した分析が可能です。
Sumo Logic はクラウドネイティブな製品でして、AWS 上で稼働しております。そのため、ログ量を増やしていっても利用者側でプロビジョニングが不要です。もちろん急激なログの増加にも対応しておりますので、それら含めて将来的に見ても運用工数が少ないと言えます。
今回、メトリクスのクエリをご紹介させていただきましたが、下記のようにログとメトリクスを掛け合わせた分析も可能です。そのため、非常に迅速な原因究明に繋がると言えます。例えば、ログではプロセスとその数の確認を行い、実際の CPU、メモリの稼働をメトリクスで知るなどして、リスク度合いを知る / もしくは測ることで、インシデントを軽減できるということです。
メトリクス（Apache WEB サーバの CPU 負荷率） + ログ（Apache エラーログ数）の図
Sumo Logic が組み込みで「どこの」「何を」見るべきかを可視化するダッシュボードのテンプレートが揃っております。データさえ収集すればあとは簡単に状況の把握や分析に繋げていただけます。
Sumo Logic が特許を取得している LogReduce（大量データのノイズを除去した検索）や LogCompare（過去データとのログ比較）なども使うことが出来ます。さらには、異常値検出や将来の傾向分析も可能です。さらに CrowdStrike の脅威情報を継続して取り込んでいるデータベースも標準で搭載されており、セキュリティ脅威に該当する IP や昨今、世界的に見ても被害が増加しているマルウェア検知にも使用できます。
まとめ
今回は、Sumo Logic でログとメトリクスの監視するため冒頭紹介したメトリクスを収集するメリットに沿った実装を行ってみました。簡単にデータを一元管理できることや、シンプルなクエリの書き方に加え、AppCatalog による簡単に要点を押さえたダッシュボードを作成できました。SaaS 製品の魅力でもありますが、何かを始めるときに工数を大幅に削減できるのもメリットだと思います。もし、本記事で紹介させていただいた内容で課題等ございましたらお気軽にお問い合わせください。
